home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pppext-for-bridging-00.txt < prev    next >
Text File  |  1993-07-08  |  43KB  |  1,119 lines
  1.  
  2.  
  3.  
  4. INTERNET-DRAFT                                             F. Baker, ACC
  5. Network Working Group                                      R. Bowen, IBM
  6.                                                                  Editors
  7.                                                               July, 1993
  8.  
  9.  
  10.             Point-to-Point Protocol Extensions for Bridging
  11.  
  12.  
  13. STATUS OF THIS MEMO
  14.  
  15.    This document is an Internet-Draft.  Internet-Drafts are
  16.    working documents of the Internet Engineering Task Force
  17.    (IETF), its Areas, and its Working Groups.  Note that other
  18.    groups may also distribute working documents as Internet-Drafts.
  19.    Internet-Drafts are draft documents valid for a maximum of six
  20.    months.  Internet-Drafts may be updated, replaced, or obsoleted
  21.    by other documents at any time.  It is not appropriate to use
  22.    Internet-Drafts as reference material or to cite them other
  23.    than as a ``working draft'' or ``work in progress.''
  24.  
  25.    To learn the current status of any Internet-Draft, please check
  26.    the 1id-abstracts.txt listing contained in the Internet-Drafts
  27.    Shadow Directories on ds.internic.net, nic.nordu.net,
  28.    ftp.nisc.sri.com, or munnari.oz.au.
  29.  
  30.    This document will expire no later than January 15, 1994.
  31.  
  32.  
  33. 1. Abstract
  34.  
  35.    This document defines an extension of the Internet Point-to-Point
  36.    Protocol (PPP) described in RFC 1331, targeting the use of Point-to-
  37.    Point lines for Remote Bridging.  It is intended as an update to
  38.    replace RFC 1220.  This draft is a product of the Point-to-Point
  39.    Protocol Extensions Working Group of the Internet Engineering
  40.    Task Force (IETF).
  41.  
  42.    This Internet-Draft specifies an IAB standards track protocol for the
  43.    Internet community, and requests discussion and suggestions for
  44.    improvements.  Please refer to the current edition of the "IAB
  45.    Official Protocol Standards" for the standardization state and
  46.    status of this protocol.  Distribution of this memo is unlimited.
  47.  
  48.  
  49. 2.  Historical Perspective
  50.  
  51.    Two basic algorithms are ambient in the industry for Bridging of
  52.  
  53.  
  54.  
  55. Point-to-Point Protocol Extensions Working Group               [Page  1]
  56.  
  57. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  58.  
  59.  
  60.    Local Area Networks.  The more common algorithm is called
  61.    "Transparent Bridging" and has been standardized for Extended LAN
  62.    configurations by IEEE 802.1.  The other is called "Source Route
  63.    Bridging" and is prevalent on IEEE 802.5 Token Ring LANs.  The IEEE
  64.    has combined these two methods into a device called a Source Routing
  65.    Transparent (SRT) bridge, which concurrently provides both Source
  66.    Route and Transparent bridging.  Transparent and SRT bridges are
  67.    specified in IEEE standard 802.1D.
  68.  
  69.    Although there is a subcommittee of IEEE 802.1 addressing remote
  70.    bridging, neither standard directly defines Remote Bridging per se,
  71.    as that would technically be beyond the IEEE 802 committee's charter.
  72.    Both allow for it, however, modeling the line as an unspecified
  73.    interface between remote bridges.
  74.  
  75.    This document assumes that the devices at either end of a serial link
  76.  
  77.       - have agreed to utilize the RFC 1331 line discipline in some
  78.         form.
  79.  
  80.       - may have agreed, by some other means, to exchange other
  81.         protocols on the line interspersed with each other and with any
  82.         bridged PDUs.
  83.  
  84.       - may be willing to use the link as a vehicle for Remote Bridging.
  85.  
  86.       - may have multiple point-to-point links that are configured in
  87.         parallel to simulate a single line of higher speed or
  88.         reliability, but message sequence issues are solved by the
  89.         transmitting end.
  90.  
  91. 3.  General Considerations
  92.  
  93. 3.1.  Link Quality Monitoring
  94.  
  95.    It is strongly recommended that Point-to-Point Bridge Protocol
  96.    implementations utilize Magic Number Loopback Detection and Link-
  97.    Quality-Monitoring.  This is because the 802.1 Spanning Tree
  98.    protocol, which is integral to both Transparent Bridging and Source
  99.    Routing (as standardized), is unidirectional during normal operation,
  100.    with HELLO PDUs emanating from the Root System in the general
  101.    direction of the leaves, without any reverse traffic except in
  102.    response to network events.
  103.  
  104. 3.2.  Message Sequence
  105.  
  106.    The multiple link case requires consideration of message
  107.    sequentiality.  The transmitting station must determine either that
  108.    the protocol being bridged requires transmissions to arrive in the
  109.    order of their original transmission, and enqueue all transmissions
  110.    on a given conversation onto the same link to force order
  111.  
  112.  
  113.  
  114. Point-to-Point Protocol Extensions Working Group               [Page  2]
  115.  
  116. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  117.  
  118.  
  119.    preservation, or that the protocol does NOT require transmissions to
  120.    arrive in the order of their original transmission, and use that
  121.    knowledge to optimize the utilization of the several links, enqueuing
  122.    traffic to links to minimize delay.
  123.  
  124.    In the absence of such a determination, the transmitting station must
  125.    act as though all protocols require order preservation; many
  126.    protocols designed primarily for use on a single LAN in fact do.  A
  127.    protocol could be described to maintain message sequentiality across
  128.    multiple links, either by sequence numbering or by fragmentation and
  129.    re-assembly, but this is neither elegant nor absolutely necessary.
  130.  
  131. 3.3.  Maximum Receive Unit Considerations
  132.  
  133.    Please note that the negotiated MRU must be large enough to support
  134.    the MAC Types that are negotiated for support, there being no
  135.    fragmentation and re-assembly.  Even Ethernet frames are larger than
  136.    the default MRU of 1500 octets.
  137.  
  138. 3.4.  Separation of Spanning Tree Domains
  139.  
  140.    It is conceivable that a network manager might wish to inhibit the
  141.    exchange of BPDUs on a link in order to logically divide two regions
  142.    into separate Spanning Trees with different Roots (and potentially
  143.    different Spanning Tree implementations or algorithms).  In order to
  144.    do that, he should configure both ends to not exchange BPDUs on a
  145.    link.  For the sake of robustness, a bridge which is so configured
  146.    must silently discard the BPDU of its neighbor, should it receive
  147.    one.
  148.  
  149. 4.  IEEE 802.1 Bridging
  150.  
  151. 4.1.  Overview of IEEE 802.1 Transparent Bridging
  152.  
  153.    As a favor to the uninitiated, let us first describe Transparent
  154.    Bridging.  Essentially, the bridges in a network operate as isolated
  155.    entities, largely unaware of each others' presence.  A Transparent
  156.    Bridge maintains a Forwarding Database consisting of
  157.  
  158.             {address, interface}
  159.  
  160.    records by saving the Source Address of each LAN transmission that it
  161.    receives along with the interface identifier for the interface it was
  162.    received on.  It goes on to check whether the Destination Address is
  163.    in the database, and if so, either discards the message (if the
  164.    destination and source are located at the same interface) or forwards
  165.    the message to the indicated interface.  A message whose Destination
  166.    Address is not found in the table is forwarded to all interfaces
  167.    except the one it was received on; this describes Broadcast/Multicast
  168.    behavior as well.
  169.  
  170.  
  171.  
  172.  
  173. Point-to-Point Protocol Extensions Working Group               [Page  3]
  174.  
  175. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  176.  
  177.  
  178.    The obvious fly in the ointment is that redundant paths in the
  179.    network cause indeterminate (nay, all too determinate) forwarding
  180.    behavior to occur.  To prevent this, a protocol called the IEEE
  181.    802.1D Spanning Tree Protocol is executed between the bridges to
  182.    detect and logically remove redundant paths from the network.
  183.  
  184.    One system is elected as the "Root", which periodically emits a
  185.    message called a Bridge Protocol Data Unit, or BPDU, heard by
  186.    all of its neighboring bridges.  Each of these modifies and passes
  187.    the BPDU on to its neighbors, and they to theirs, until it arrives at
  188.    the leaf LAN segments in the network (where it dies, having no
  189.    further neighbors to pass it along) or until the message is stopped
  190.    by a bridge which has a superior path to the "Root".  In this latter
  191.    case, the interface the BPDU was received on is ignored (i.e., it is
  192.    placed in a Hot Standby status, no traffic is emitted onto it except
  193.    the BPDU, and all traffic received from it is discarded) until a
  194.    topology change forces a recalculation of the network.
  195.  
  196. 4.2.  IEEE 802.1 Remote Transparent Bridging Activity
  197.  
  198.    There exist two basic sorts of bridges - ones that interconnect LANs
  199.    directly, called Local Bridges, and ones that interconnect LANs via
  200.    an intermediate medium such as a leased line, called Remote Bridges.
  201.    The Point-to-Point Protocol might be used by a Remote Bridge.
  202.  
  203.    There is more than one proposal within the IEEE 802.1 Interworking
  204.    Committee for modeling the Remote Bridge.  In one model, the
  205.    interconnecting serial link(s) are treated in the same way that a LAN
  206.    is, having a standard IEEE 802.1 Link State; in another, the serial
  207.    links operate in a mode quite different from the LANs that they
  208.    interconnect.  For the sake of simplicity of specification, the first
  209.    model is adopted, although some of the good ideas from proponents of
  210.    the second model are included or allowed for.
  211.  
  212.    Therefore, given that transparent bridging is configured on a line or
  213.    set of lines, the specifics of the link state with respect to the
  214.    bridge is defined by IEEE 802.1D.  The Bridge Protocol Data Unit,
  215.    or BPDU, is defined there, as well as the algorithms for its use.
  216.  
  217.    It is assumed that, if a Point-to-Point Link neighbor receives IEEE
  218.    802.1 BPDUs without rejecting them with the RFC 1331 Protocol-Reject
  219.    LCP PDU, Transparent Bridging is permitted on the link.
  220.  
  221. 4.3.  IEEE 802.1 Source Routing
  222.  
  223.    The IEEE 802.1D Committee has standardized Source Routing for any MAC
  224.    Type that allows its use.  Currently, MAC Types that support Source
  225.    Routing are FDDI and IEEE 802.5 Token Ring.
  226.  
  227.    In this approach, the originating system has the responsibility of
  228.    indicating what path the message should follow.  It does this,
  229.  
  230.  
  231.  
  232. Point-to-Point Protocol Extensions Working Group               [Page  4]
  233.  
  234. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  235.  
  236.  
  237.    if the message is directed off the local ring, by including a
  238.    variable length MAC header extension called the Routing Information
  239.    Field, or RIF.  The RIF consists of one 16 bit word of flags and
  240.    parameters followed by zero or more ring-and-bridge identifiers.
  241.    Each bridge en route determines from this "source route list"
  242.    whether it should receive the message and how to forward it.
  243.  
  244.    The algorithm for Source Routing requires the bridge to be able to
  245.    identify any interface by its ring-and-bridge identifier, and to be
  246.    able to identify any of its OTHER interfaces likewise.  When a packet
  247.    is received which has the Routing Information Field (RIF) present, a
  248.    boolean in the RIF is inspected to determine whether the ring-and-
  249.    bridge identifiers are to be inspected in "forward" or "reverse"
  250.    sense.  In a "forward" search, the bridge looks for the ring-and-
  251.    bridge identifier of the interface the packet was received on, and
  252.    forwards the packet toward the ring identified in the ring-and-bridge
  253.    identifier that follows it.  In a "reverse" search, the bridge looks
  254.    for the ring-and-bridge identifier of the OTHER INTERFACE, and
  255.    delivers the packet to the indicated interface if such is found.
  256.  
  257. 4.4.  IEEE 802.1 Remote Source Route Bridging Activity
  258.  
  259.    There is no Remote Source Route Bridge proposal in IEEE 802.1 at this
  260.    time, although IBM ships a remote Source Routing Bridge.  Simplicity
  261.    would dictate that we choose the same model for remote Source Routing
  262.    that was selected for IEEE 802.1, but necessity requires a ring
  263.    number for the line in some cases.  We allow for both models.
  264.  
  265.    Given that source routing is configured on a line or set of lines,
  266.    the specifics of the link state with respect to the bridge is defined
  267.    by the IEEE 802.1 Appendix on Source Routing.  The requisite PDUs for
  268.    calculating the spanning tree (used for assuring that each ring will
  269.    receive at most one copy of a multicast) are defined there, as well
  270.    as the algorithms for their use.  MAC PDUs (Beacon, Ring Management,
  271.    etc) are specific to the MAU technology and are not exchanged on the
  272.    line.
  273.  
  274. 4.5.  Source Routing to Transparent Bridge Translation
  275.  
  276.    IEEE 802 is not currently addressing bridges that translate between
  277.    Transparent Bridging and Source Routing.  For the purposes of this
  278.    standard, such a device is either a Transparent or a Source Routing
  279.    bridge, and will act on the line in one of these two ways, just as
  280.    it does on the LAN.
  281.  
  282. 5.  Traffic Services
  283.  
  284.    Several services are provided for the benefit of different system
  285.    types and user configurations.  These include LAN Frame Checksum
  286.    Preservation, LAN Frame Checksum Generation, Tinygram Compression,
  287.    and the identification of closed sets of LANs.
  288.  
  289.  
  290.  
  291. Point-to-Point Protocol Extensions Working Group               [Page  5]
  292.  
  293. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  294.  
  295.  
  296. 5.1.  LAN Frame Checksum Preservation
  297.  
  298.    IEEE 802.1 stipulates that the Extended LAN must enjoy the same
  299.    probability of undetected error that an individual LAN enjoys.
  300.    Although there has been considerable debate concerning the algorithm,
  301.    no other algorithm has been proposed than having the LAN Frame
  302.    Checksum received by the ultimate receiver be the same value
  303.    calculated by the original transmitter.  Achieving this requires, of
  304.    course, that the line protocols preserve the LAN Frame Checksum from
  305.    end to end.  The protocol is optimized towards this approach.
  306.  
  307. 5.2.  Traffic having no LAN Frame Checksum
  308.  
  309.    The fact that the protocol is optimized towards LAN Frame Checksum
  310.    preservation raises twin questions: "What is the approach to be used
  311.    by systems which, for whatever reason, cannot easily support Frame
  312.    Checksum preservation?" and "What is the approach to be used when the
  313.    system originates a message, which therefore has no Frame Checksum
  314.    precalculated?".
  315.  
  316.    Surely, one approach would be to require stations to calculate the
  317.    Frame Checksum in software if hardware support were unavailable; this
  318.    would meet with profound dismay, and would raise serious questions of
  319.    interpretation in a Bridge/Router.
  320.  
  321.    However, stations which implement LAN Frame Checksum preservation
  322.    must already solve this problem, as they do originate traffic.
  323.    Therefore, the solution adopted is that messages which have no Frame
  324.    Checksum are tagged and carried across the line.
  325.  
  326.    When a system which does not implement LAN Frame Checksum
  327.    preservation receives a frame having an embedded FCS, it converts it
  328.    for its own use by removing the trailing four octets.  When any
  329.    system forwards a frame which contains no embedded FCS to a LAN, it
  330.    forwards it in a way which causes the FCS to be calculated.
  331.  
  332. 5.3.  Tinygram Compression
  333.  
  334.    An issue in remote Ethernet bridging is that the protocols that are
  335.    most attractive to bridge are prone to problems on low speed (64 KBPS
  336.    and below) lines.  This can be partially alleviated by observing that
  337.    the vendors defining these protocols often fill the PDU with octets
  338.    of ZERO.  Thus, an Ethernet or IEEE 802.3 PDU received from a line
  339.    that is (1) smaller than the minimum PDU size, and (2) has a LAN
  340.    Frame Checksum present, must be padded by inserting zeroes between
  341.    the last four octets and the rest of the PDU before transmitting it
  342.    on a LAN.  These protocols are frequently used for interactive
  343.    sessions, and therefore are frequently this small.
  344.  
  345.    To prevent ambiguity, PDUs requiring padding are explicitly tagged.
  346.    Compression is at the option of the transmitting station, and is
  347.  
  348.  
  349.  
  350. Point-to-Point Protocol Extensions Working Group               [Page  6]
  351.  
  352. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  353.  
  354.  
  355.    probably performed only on low speed lines, perhaps under
  356.    configuration control.
  357.  
  358.    The pseudo-code in Figure 1 describes the algorithms.
  359.  
  360. 5.4.  LAN Identification
  361.  
  362.    In some applications, it is useful to tag traffic by the user
  363.    community it is a part of, and guarantee that it will be only emitted
  364.    onto a LAN which is of the same community.  The user community is
  365.    defined by a LAN ID.  Systems which choose to not implement this
  366.    feature must assume that any frame received having a LAN ID is from a
  367.    different community than theirs, and discard it.
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409. Point-to-Point Protocol Extensions Working Group               [Page  7]
  410.  
  411. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  412.  
  413.  
  414. Figure 1: Tinygram Compression Pseudo-Code
  415.  
  416. PPP Transmitter:
  417.  
  418. if (ZeroPadCompressionEnabled &&
  419.     BridgedProtocolHeaderFormat == IEEE8023 &&
  420.     PacketLength == Minimum8023PacketLength) {
  421.  /*
  422.   * Remove any continuous run of zero octets preceding,
  423.   * but not including, the LAN FCS, but not extending
  424.   * into the MAC header.
  425.   */
  426.     Set (ZeroCompressionFlag);            /* Signal receiver */
  427.     if (is_Set (LAN_FCS_Present)) {
  428.         FCS = TrailingOctets (PDU, 4);    /* Store FCS */
  429.         RemoveTrailingOctets (PDU, 4);    /* Remove FCS */
  430.         while (PacketLength > 14 &&       /* Stop at MAC header */
  431.                TrailingOctet (PDU) == 0)  /*  or last non-zero octet */
  432.             RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
  433.         Appendbuf (PDU, 4, FCS);          /* Restore FCS */
  434.     }
  435.     else {
  436.         while (PacketLength > 14 &&       /* Stop at MAC header */
  437.                TrailingOctet (PDU) == 0)  /*  or last zero octet */
  438.             RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
  439.     }
  440. }
  441.  
  442. PPP Receiver:
  443.  
  444. if (ZeroCompressionFlag) {                /* Flag set in header? */
  445.  /* Restoring packet to minimum 802.3 length */
  446.     Clear (ZeroCompressionFlag);
  447.     if (is_Set (LAN_FCS_Present)) {
  448.         FCS = TrailingOctets (PDU, 4);   /* Store FCS */
  449.         RemoveTrailingOctets (PDU, 4);   /* Remove FCS */
  450.         Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
  451.         Appendbuf (PDU, 4, FCS);         /* Restore FCS */
  452.     }
  453.     else {
  454.         Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
  455.     }
  456. }
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468. Point-to-Point Protocol Extensions Working Group               [Page  8]
  469.  
  470. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  471.  
  472.  
  473. 6.  Protocol Data Unit Formats
  474.  
  475. 6.1.  Common LAN Traffic
  476.  
  477.    Figure 2: 802.3 Frame format
  478.  
  479.     0                   1                   2                   3
  480.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  481.    +-+-+-+-+-+-+-+-+
  482.    |   HDLC FLAG   |
  483.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  484.    |      0xFF     |      0x03     |      0x00     |      0x31     +
  485.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  486.    |F|I|Z|0| Count |    MAC Type   |  LAN ID high word (optional)  +
  487.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  488.    |   LAN ID low word (optional)  |      Destination MAC Address  +
  489.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  490.    |                       Destination MAC Address                 +
  491.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  492.    |                       Source MAC Address                      +
  493.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  494.    |     Source MAC Address        |      Length/Type              +
  495.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  496.    |               LLC data                                        +
  497.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  498.    |                              ...                              +
  499.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  500.    |                   LAN FCS (optional)                          +
  501.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  502.    |                potential line protocol pad                    +
  503.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  504.    |           HDLC CRC            |   HDLC FLAG   |
  505.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  506.  
  507.    For Bridging LAN traffic, the format of the frame on the line is as
  508.    shown in Figures 2 or 3.  This conforms to RFC 1331 section 3.1
  509.    "Frame Format".  It also allows for RFC 1331 negotiation of
  510.    Protocol Field Compression and Address and Control Field Compression.
  511.    It is recommended that devices which use controllers that require
  512.    even memory addresses negotiate to NOT USE Protocol Field Compression
  513.    on other than low speed links.
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527. Point-to-Point Protocol Extensions Working Group               [Page  9]
  528.  
  529. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  530.  
  531.  
  532.    Figure 3: 802.4/802.5/FDDI Frame format
  533.  
  534.     0                   1                   2                   3
  535.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  536.    +-+-+-+-+-+-+-+-+
  537.    |   HDLC FLAG   |
  538.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  539.    |      0xFF     |      0x03     |      0x00     |      0x31     +
  540.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  541.    |F|I|Z|0| Count |    MAC Type   |  LAN ID high word (optional)  +
  542.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  543.    |   LAN ID low word (optional)  |   Pad Byte    | Frame Control +
  544.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  545.    |                       Destination MAC Address                 +
  546.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  547.    |     Destination MAC Address   |  Source MAC Address           +
  548.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  549.    |                       Source MAC Address                      +
  550.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  551.    |               LLC data                                        +
  552.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  553.    |                              ...                              +
  554.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  555.    |                       FCS (optional)                          +
  556.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  557.    |              optional Data Link Layer padding                 +
  558.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  559.    |           HDLC CRC            |   HDLC FLAG   |
  560.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  561.  
  562.  
  563. The fields of this message are as follows:
  564.  
  565. Address Field and Control Field:
  566.      As defined by RFC 1331
  567.  
  568. Protocol Field:
  569.      0x0031
  570.  
  571. Flags:
  572.      bits 0-3: length of the line protocol pad field.
  573.      bit 4:  Reserved, Set to Zero
  574.      bit 5:  Set if IEEE 802.3 Pad must be zero filled to minimum size
  575.      bit 6:  Set if the LAN ID Field is present
  576.      bit 7:  Set if the LAN FCS Field is present
  577.  
  578.      The "number of trailing "pad" octets is a deference to the fact
  579.      that any point-to-point frame may have padding at the end.  This
  580.      number tells the receiving system how many octets to strip off the
  581.      end.
  582.  
  583.  
  584.  
  585.  
  586. Point-to-Point Protocol Extensions Working Group               [Page 10]
  587.  
  588. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  589.  
  590.  
  591. MAC Type:
  592.      0x00: Reserved
  593.      0x01: IEEE 802.3/Ethernet (canonical addresses)
  594.      0x02: IEEE 802.4 (non-canonical addresses)
  595.      0x03: IEEE 802.5 (non-canonical addresses)
  596.      0x04: FDDI (non-canonical addresses)
  597.      0xXX: FDDI (canonical addresses) [to be assigned - 0x0C proposed]
  598.      other:  Assigned by the Internet Assigned Numbers Authority
  599.  
  600. LAN ID:
  601.      This optional 32 bit field identifies the Community of LANs which
  602.      may be interested to receive this frame, as described in section
  603.      5.4.  If the LAN ID flag is not set, then this field is not
  604.      present, and the PDU is four octets shorter.
  605.  
  606. Frame Control:
  607.      On 802.4, 802.5, and FDDI LANs, there are a few octets preceding
  608.      the Destination MAC Address, one of which is protected by the FCS.
  609.      Since the MAC Type field defines the bit ordering, these are sent
  610.      in MAC order.  A pad octet is present to avoid odd machine address
  611.      boundary problems.
  612.  
  613. Destination MAC Address:
  614.      As defined by the IEEE.  Since the MAC Type field defines the bit
  615.      ordering, this is sent in MAC order.
  616.  
  617. Source MAC Address:
  618.      As defined by the IEEE.  Since the MAC Type field defines the bit
  619.      ordering, this is sent in MAC order.
  620.  
  621. LLC data:
  622.      This is the remainder of the MAC frame.  This is that portion of
  623.      the frame which is (or would be were it present) protected by the
  624.      LAN FCS; for example, the 802.5 Access Control field, and Status
  625.      Trailer are not meaningful to transmit to another ring, and are
  626.      omitted.
  627.  
  628. LAN Frame Checksum:
  629.      If present, this is the LAN FCS which was calculated by (or which
  630.      appears to have been calculated by) the originating station.  If
  631.      the FCS Present flag is not set, then this field is not present,
  632.      and the PDU is four octets shorter.
  633.  
  634. Optional Data Link Layer Padding
  635.      RFC 1331 specifies that an arbitrary pad can be added after the
  636.      data intended for transmission.  The "Count" portion of the flag
  637.      field contains the length of this pad, which may not exceed 15
  638.      octets.
  639.  
  640.      The PPP Extensions in RFC XXXX, "PPP LCP Extensions," specify a
  641.      self-describing pad.  Implementations are encouraged to set the
  642.  
  643.  
  644.  
  645. Point-to-Point Protocol Extensions Working Group               [Page 11]
  646.  
  647. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  648.  
  649.  
  650.      Count field to zero and use the self-describing pad instead.
  651.  
  652. CRC-CCITT
  653.      Mentioned primarily for clarity.  The CRC used on the PPP link is
  654.      separate from and unrelated to the LAN FCS.
  655.  
  656. 6.2.  Spanning Tree Bridge PDU
  657.  
  658.    This is the Spanning Tree BPDU, without any MAC or
  659.    802.2 LLC header (these being functionally equivalent to the Address,
  660.    Control, and Protocol Fields).  The LAN Pad and Frame Checksum fields
  661.    are likewise superfluous and absent. The Address and Control Fields
  662.    are optional, subject to the Address and Control Field Compression
  663.    negotiation.
  664.  
  665.    If a Point-to-Point Link neighbor receives a BPDU without rejecting
  666.    it with the RFC 1331 Protocol-Reject LCP PDU, then either the
  667.    specified spanning tree protocol is supported or spanning tree
  668.    support is disabled so as to separate two spanning tree domains.
  669.  
  670.    Figure 4: Spanning Tree Bridge PDU
  671.  
  672.     0                   1                   2                   3
  673.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  674.    +-+-+-+-+-+-+-+-+
  675.    |   HDLC FLAG   |
  676.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  677.    |      0xFF     |      0x03     |     Spanning Tree Protocol    +
  678.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  679.    |              BPDU data                                        +
  680.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  681.    |                              ...                              +
  682.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  683.    |           HDLC CRC            |   HDLC FLAG   |
  684.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  685.  
  686.  
  687.    The fields of this message are as follows:
  688.  
  689.    Address Field and Control Field:
  690.         As defined by RFC 1331
  691.  
  692.    Protocol Field:
  693.         0x0201: IEEE 802.1D Spanning Tree
  694.         0x0203: IBM Source Route Bridge Spanning Tree
  695.         other:  Assigned by the Internet Assigned Numbers Authority
  696.  
  697.    MAC Frame:
  698.         BPDU, as defined by the specified Spanning Tree Protocol
  699.  
  700.  
  701.  
  702.  
  703.  
  704. Point-to-Point Protocol Extensions Working Group               [Page 12]
  705.  
  706. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  707.  
  708.  
  709. 6.3.  IEEE 802 Network Control Protocol
  710.  
  711.    The Bridge Network Control Protocol is responsible for configuring,
  712.    enabling, and disabling the bridges on both ends of the point-to-
  713.    point link.  As with the Link Control Protocol, this is accomplished
  714.    through an exchange of packets.  BNCP packets may not be exchanged
  715.    until LCP has reached the network-layer Protocol Configuration
  716.    Negotiation phase.  Likewise, LAN traffic may not be exchanged until
  717.    BNCP has first opened the connection.
  718.  
  719.    The Bridge Network Control Protocol is exactly the same as the Point-
  720.    to-Point Link Control Protocol with the following exceptions:
  721.  
  722.    Data Link Layer Protocol Field
  723.         Exactly one Bridge Network Control Protocol packet is encapsu-
  724.         lated in the Information field of PPP Data Link Layer frames
  725.         where the Protocol field indicates type hex 8031 (BNCP).
  726.  
  727.    Code field
  728.         Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  729.         Configure-Nak, Configure-Reject, Terminate-Request,
  730.         Terminate-Ack and Code-Reject) are used.  Other Codes should
  731.         be treated as unrecognized and should result in Code-Rejects.
  732.  
  733.    Timeouts
  734.         BNCP packets may not be exchanged until the Link Control
  735.         Protocol has reached the network-layer Protocol Configuration
  736.         Negotiation phase.  An implementation should be prepared to wait
  737.         for Link Quality testing to finish before timing out waiting
  738.         for Configure-Ack or other response.
  739.  
  740.    Configuration Option Types
  741.         The Bridge Network Control Protocol has a separate set of
  742.         Configuration Options.  These permit the negotiation of the
  743.         following items:
  744.  
  745.              - MAC Types supported
  746.              - Tinygram Compression support
  747.              - LAN Identification support
  748.              - Ring and Bridge Identification
  749.  
  750. 6.4.  Source Routing Remote Ring Identification Option
  751.  
  752.    The Source Routing Remote Ring Identification Option is designed for
  753.    use when the line is an interface between half bridges connecting
  754.    virtual or physical rings.
  755.  
  756.    Since the remote bridges are modeled as a single bridge with a
  757.    strange internal interface, each remote bridge needs to know the
  758.    ring/bridge numbers of the remote bridge it is adjacent to.  This is
  759.    the subject of a Link Negotiation.  The exchange of ring-and-bridge
  760.  
  761.  
  762.  
  763. Point-to-Point Protocol Extensions Working Group               [Page 13]
  764.  
  765. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  766.  
  767.  
  768.    identifiers is done using this option on the Network Control
  769.    Protocol.
  770.  
  771.    The two half bridges must agree on the bridge number.  When the two
  772.    disagree, the larger of the two numbers should be used.  To resolve
  773.    the conflict, the system with the higher bridge number should NAK the
  774.    option, suggesting its own bridge number for use.
  775.  
  776.    The Token Ring Ring-and-Bridge Identifier, and its use, is specified
  777.    by the IEEE 802.1D Appendix on Source Routing.  It identifies the
  778.    ring that the interface is attached to by its configured ring number,
  779.    and itself by bridge number on the ring.
  780.  
  781.    Figure 5: Remote Ring Identification Option
  782.  
  783.     0                   1                   2                   3
  784.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  785.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  786.    |     type=1    |length = 4     | ring number           |bridge#|
  787.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  788.  
  789.    Type 1 =  Source Routing Ring/Bridge Identifier
  790.  
  791.    Length
  792.         4 Octets
  793.  
  794.    Ring Number
  795.         A 12 bit number identifying the token ring, as defined in the
  796.         IEEE 802.1D Source Routing Specification.
  797.  
  798.    Bridge Number
  799.         A 4 bit number identifying the bridge on the token ring, as
  800.         defined in the IEEE 802.1D Source Routing Specification.
  801.  
  802.    For example, if System A announces
  803.  
  804.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  805.       |            AAA        |   1   |
  806.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  807.  
  808.    and System B announces
  809.  
  810.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  811.       |            BBB        |   1   |
  812.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822. Point-to-Point Protocol Extensions Working Group               [Page 14]
  823.  
  824. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  825.  
  826.  
  827.    then the resulting Source Routing Tuple (read in the appropriate
  828.    direction) is then
  829.  
  830.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  831.       |            AAA        |   1   |         BBB           |
  832.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.
  833.  
  834. 6.5.  Source Routing Line Identification Option
  835.  
  836.    The Source Routing Line Identification Option is designed for use
  837.    when the line is assigned a ring number as though it were a two
  838.    system token ring in accordance with the Source Routing algorithm.
  839.    The bridges exchange ring-and-bridge identifiers using this option
  840.    on the Network Control Protocol.
  841.  
  842.    The Token Ring Ring-and-Bridge Identifier, and its use, is specified
  843.    by the IEEE 802.1D Appendix on Source Routing.  It identifies the
  844.    ring that the interface is attached to by its configured ring number,
  845.    and itself by bridge number on the ring.
  846.  
  847.    The two bridges must agree on the ring number.  When the two
  848.    disagree, the larger of the two numbers should be used.  To resolve
  849.    the conflict, the system with the higher ring number should NAK the
  850.    option, suggesting its own ring number for use.
  851.  
  852.    Figure 6: Line Identification Option
  853.  
  854.     0                   1                   2                   3
  855.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  856.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  857.    |     type=2    |length = 4     | ring number           |bridge#|
  858.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  859.  
  860.  
  861.    Type 2 = Source Routing Line "Ring/Bridge" Identifier
  862.  
  863.    Length
  864.         4 Octets
  865.  
  866.    Ring Number
  867.         A 12 bit number identifying the line, as defined in the
  868.         IEEE 802.1D Source Routing Specification.
  869.  
  870.    Bridge Number
  871.         A 4 bit number identifying the bridge on the token ring, as
  872.         defined in the IEEE 802.1D Source Routing Specification.
  873.  
  874. 6.6.  MAC Type Support Selection
  875.  
  876.    Note:  During the Proposed Standard stage of RFC 1220, this option
  877.    was not widely implemented and implementations have not necessarily
  878.  
  879.  
  880.  
  881. Point-to-Point Protocol Extensions Working Group               [Page 15]
  882.  
  883. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  884.  
  885.  
  886.    proven interoperable.  Its use is therefore discouraged.
  887.  
  888.    The MAC Type Selection Option is provided to permit nodes to
  889.    advertise what sort of traffic they are prepared to convey.  A device
  890.    negotiating a 1600 octet MRU, for example, may not be willing to
  891.    support 802.5 (although it might, with certain changes necessary in
  892.    the RIFs it passes, and given that the hosts it supports implement
  893.    the 802.5 Maximum Frame Size correctly), and is definitely not
  894.    prepared to support 802.4 or FDDI.
  895.  
  896.    A system which does not announce the MAC Types that it supports may
  897.    be assumed to support all MAC Types; it will discard those that it
  898.    does not understand.  A system which chooses to announce MAC Types is
  899.    advising its neighbor that all unspecified MAC Types will be
  900.    discarded.  Announcement of multiple MAC Types is accomplished by
  901.    placing multiple options in the Configure Request.
  902.  
  903.    The Rejection of a MAC Type Announcement (in a Configure-Reject) is
  904.    essentially a statement that traffic appropriate to the MAC Type, if
  905.    encountered, will be forwarded on the link even though the receiving
  906.    system has indicated it will discard it.
  907.  
  908.    Figure 7: MAC Type Selection Option
  909.  
  910.     0                   1                   2
  911.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  912.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  913.    |     type=3    |length = 3     | MAC Type      |
  914.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  915.  
  916.  
  917.    Type 3 = MAC Type Selector
  918.  
  919.    Length
  920.         3 Octets
  921.  
  922.    MAC Type Selector
  923.         One of the values of the PDU's MAC Type Field that this system
  924.         is prepared to receive and service.
  925.  
  926. 6.7.  Tinygram Compression
  927.  
  928.    Not all systems are prepared to make modifications to messages in
  929.    transit; on high speed lines, it is probably not worth the effort.
  930.    This option permits the system to negotiate compression.
  931.  
  932.    Consistent with the behavior of other compression options in the
  933.    Internet Point-to-Point set of protocols, no negotiation implies no
  934.    compression.  The systems need not agree on the setting of this
  935.    parameter; one may be willing to decompress and the other not.  A
  936.    system which does not negotiate, or negotiates this option to be
  937.  
  938.  
  939.  
  940. Point-to-Point Protocol Extensions Working Group               [Page 16]
  941.  
  942. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  943.  
  944.  
  945.    disabled, should never receive a compressed packet, however.
  946.  
  947.    Figure 8: Tinygram Compression Option
  948.  
  949.     0                   1                   2
  950.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  951.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  952.    |     type=4    |length = 3     | Compression   |
  953.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  954.  
  955.  
  956.    Type 4 = Tinygram Compression Support Option
  957.  
  958.    Length
  959.         3 Octets
  960.  
  961.    Compression Enable/Disable
  962.         If the value is 1, Tinygram Compression is enabled.  If the
  963.         value is 2, Tinygram Compression is disabled, and no
  964.         decompression will occur.
  965.  
  966. 6.8.  LAN Identification Support
  967.  
  968.    Note:  Implementors are advised that during the Proposed Standard
  969.    stage of RFC 1220 this option was not widely implemented.
  970.  
  971.    Not all systems are prepared to make use of the LAN Identification
  972.    field.  This option enables the systems to negotiate its use.
  973.  
  974.    The parameter is advisory; if the value is "enabled", then there may
  975.    exist labeled LANs beyond the system, and the system is prepared to
  976.    service traffic to it.  if the value is "disabled", then there are no
  977.    labeled LANs beyond the system, and all such traffic will by
  978.    definition be dropped.  Therefore, a system which is advised that his
  979.    peer does not service LAN Identifications need not forward such
  980.    traffic on the link.
  981.  
  982.    The default value is that LAN Identification disabled.
  983.  
  984.    Figure 9: LAN Identification Option
  985.  
  986.     0                   1                   2
  987.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  988.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  989.    |     type=5    |length = 3     | Identification|
  990.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  991.  
  992.  
  993.    Type 5 = LAN Identification Support Option
  994.  
  995.  
  996.  
  997.  
  998.  
  999. Point-to-Point Protocol Extensions Working Group               [Page 17]
  1000.  
  1001. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  1002.  
  1003.  
  1004.    Length
  1005.         3 Octets
  1006.  
  1007.    Identification Enable/Disable
  1008.         If the value is 1, LAN Identification is enabled.  If the value
  1009.         is 2, LAN Identification is disabled.
  1010.  
  1011. 6.9.  MAC Address Specification
  1012.  
  1013.     The "MAC Address Specification" option enables the system to
  1014.     announce its MAC Address or have one assigned.  The MAC Address
  1015.     is, in this case, represented in IEEE 802.1 Canonical format,
  1016.     which is to say that the multicast bit is the least significant
  1017.     bit of the first octet of the address.
  1018.  
  1019.     If the system wishes to announce its MAC Address, it sends the
  1020.     option with its MAC Address specified.  RFC 1220 systems will
  1021.     REJECT this option, so systems should expect and ignore
  1022.     option rejects.  This option should under no circumstances be NAKed,
  1023.     however, as it is purely informational.
  1024.  
  1025.     If the system wishes to have a MAC Address assigned, it sends
  1026.     the option with a MAC Address of 00-00-00-00-00-00.  A system
  1027.     receiving this option MUST either NAK or REJECT it; Systems
  1028.     that have no mechanism for address assignment, including RFC
  1029.     1220 systems, will REJECT it.  A NAK, if presented, MUST
  1030.     specify a valid IEEE 802.1 format physical address; the
  1031.     Multicast Bit MUST therefore be zero.  It is strongly
  1032.     recommended (although not mandatory) that the "locally assigned
  1033.     address" bit (the second least significant bit in the first
  1034.     octet) be set to ONE indicating a dynamically assigned
  1035.     address.
  1036.  
  1037.     Figure 10: MAC Address Announcement or Assignment
  1038.  
  1039.      0                   1
  1040.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  1041.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1042.     |   Type = 6    |  Length = 8   |
  1043.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1044.     |MAC byte 1 |L|M|  MAC byte 2   |
  1045.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1046.     |  MAC byte 3   |  MAC byte 4   |
  1047.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1048.     |  MAC byte 5   |  MAC byte 6   |
  1049.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1050.  
  1051.     Type 6 = MAC Address Announcement
  1052.  
  1053.     Length
  1054.         8 Octets
  1055.  
  1056.  
  1057.  
  1058. Point-to-Point Protocol Extensions Working Group               [Page 18]
  1059.  
  1060. Internet-Draft      Bridging Point-to-Point Protocol           July 1993
  1061.  
  1062.  
  1063.  
  1064.     MAC Address
  1065.         6 bytes of MAC Address in 802.1 Canonical order
  1066.         follow.  For clarity, the position of the Local
  1067.         Assignment (L) and Multicast (M) bits are shown in the
  1068.         diagram.
  1069.  
  1070. 7.  Acknowledgements
  1071.  
  1072.    This document is a product of the Point-to-Point Protocol Extensions
  1073.    Working Group.  Special thanks go to Steve Senum of Network Systems,
  1074.    Dino Farinacci of 3COM, Rick Szmauz of Digital Equipment Corporation
  1075.    and Andrew Fuqua of IBM.
  1076.  
  1077. 8.  Bibliography
  1078.  
  1079.    [1] Simpson, W., "The Point-to-Point Protocol for the Transmission of
  1080.        Multi-Protocol Datagrams Over Point-to-Point Links", RFC 1331,
  1081.        May 1992.
  1082.  
  1083.    [2] Media Access Control (MAC) Bridges, Institute of Electrical
  1084.        and Electronics Engineers, July 1993.  ISO/IEC 15802-3:1993
  1085.        ANSI/IEEE Std 802.1D, 1993 edition.
  1086.  
  1087. 9.  Security Considerations
  1088.  
  1089.    Security issues are not discussed in this memo.
  1090.  
  1091. 10.  Author's Addresses
  1092.  
  1093.    Fred Baker
  1094.    Advanced Computer Communications
  1095.    720 Santa Barbara Street
  1096.    Santa Barbara, CA 93101
  1097.    Phone: (805) 963-9431
  1098.    EMail: fbaker@ACC.COM
  1099.  
  1100.    Rich Bowen
  1101.    International Business Machines Corporation
  1102.    P.O. Box 12195
  1103.    Research Triangle Park, NC  27709
  1104.    Phone: (919) 543-9851
  1105.    EMail: rkb@ralvm11.vnet.ibm.com
  1106.  
  1107.    Or send comments to: ietf-ppp@ucdavis.edu
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.                  Draft Expiration Date: January 15, 1994
  1114.  
  1115.  
  1116.  
  1117.  
  1118. Point-to-Point Protocol Extensions Working Group               [Page 19]
  1119.